This allows running a single test without having to wait for all tests
to complete.

Bootstrap has to build successfully or this won't run, so all it checks
are the tests, which are uncommon to change.

We've been seeing a pretty high rate of spurious network failures (e.g., openssl
connection reset by peer). Not clear why, but let's add a retry.

Fixes: rust-lang#84884

This solution might be considered a compromise, but I think it is the
better choice.

The results in the `closure.rs` test correctly resolve all test cases
broken as described in rust-lang#84884.

One test pattern (in both `closure_macro.rs` and
`closure_macro_async.rs`) was also affected, and removes coverage
statistics for the lines inside the closure, because the closure
includes a macro. (The coverage remains at the callsite of the macro, so
we lose some detail, but there isn't a perfect choice with macros.

Often macro implementations are split across the macro and the callsite,
and there doesn't appear to be a single "right choice" for which body
should be covered. For the current implementation, we can't do both.

The callsite is most likely to be the preferred site for coverage.

I applied this fix to all `MacroKinds`, not just `Bang`.

I'm trying to resolve an issue of lost coverage in a
`MacroKind::Attr`-based, function-scoped macro. Instead of only
searching for a body_span that is "not a function-like macro" (that is,
MacroKind::Bang), I'm expanding this to all `MacroKind`s. Maybe I should
expand this to `ExpnKind::Desugaring` and `ExpnKind::AstPass` (or
subsets, depending on their sub-kinds) as well, but I'm not sure that's
a good idea.

I'd like to add a test of the `Attr` macro on functions, but I need time
to figure out how to constract a good, simple example without external
crate dependencies. For the moment, all tests still work as expected (no
change), this new commit shouldn't have a negative affect, and more
importantly, I believe it will have a positive effect. I will try to
confirm this.

…rage

And redirect users from the old file name.

And adds tests to validate it still works.

There is an anticipated feature request to support a compiler flag that
only adds coverage for specific files (or perhaps mods). As I thought
about where that change would need to be supported, I realized that
checking the attribute in mapgen (for unused functions) was unnecessary.
The unused functions are only synthesized if they have MIR coverage, and
functions with the `no_coverage` attribute will not have been
instrumented with MIR coverage statements in the first place.

New tests confirm this.

Also, while adding tests, I updated resolved comments and FIXMEs in
other tests.

…acrum

Add support for --test-args to cargotest

This allows running a single test without having to wait for all tests
to complete.

Closes rust-lang#77260.

…lacrum

Don't check bootstrap artifacts by default

Bootstrap has to build successfully or this won't run, so all it checks
are the tests, which are uncommon to change.

Fixes rust-lang#76624.

bump deps

openssl vulns:
https://rustsec.org/advisories/RUSTSEC-2021-0056.html
https://rustsec.org/advisories/RUSTSEC-2021-0055.html

openssl-src v111.12.0+1.1.1h -> v111.15.0+1.1.1k

not latest, but newer
openssl-sys v0.9.58 -> v0.9.61
openssl v0.10.30 -> v0.10.33

curl vulns: https://curl.se/docs/vuln-7.74.0.html

curl v0.4.34 -> v0.4.36
curl-sys v0.4.39+curl-7.74.0 -> v0.4.42+curl-7.76.0

…-05, r=tmandry

Update coverage docs and command line help

r? `@tmandry`
cc: `@wesleywiser`

…used, r=tmandry

Removes unneeded check of `#[no_coverage]` in mapgen

There is an anticipated feature request to support a compiler flag that
only adds coverage for specific files (or perhaps mods). As I thought
about where that change would need to be supported, I realized that
checking the attribute in mapgen (for unused functions) was unnecessary.
The unused functions are only synthesized if they have MIR coverage, and
functions with the `no_coverage` attribute will not have been
instrumented with MIR coverage statements in the first place.

New tests confirm this.

Also, while adding tests, I updated resolved comments and FIXMEs in
other tests, and expanded comments and tests on one remaining issue that
is still not resolved.

r? `@tmandry`
cc: `@wesleywiser`

…mandry

Coverage instruments closure bodies in macros (not the macro body)

Fixes: rust-lang#84884

This solution might be considered a compromise, but I think it is the
better choice.

The results in the `closure.rs` test correctly resolve all test cases
broken as described in rust-lang#84884.

One test pattern (in both `closure_macro.rs` and
`closure_macro_async.rs`) was also affected, and removes coverage
statistics for the lines inside the closure, because the closure
includes a macro. (The coverage remains at the callsite of the macro, so
we lose some detail, but there isn't a perfect choice with macros.

Often macro implementations are split across the macro and the callsite,
and there doesn't appear to be a single "right choice" for which body
should be covered. For the current implementation, we can't do both.

The callsite is most likely to be the preferred site for coverage.

r? `@tmandry`
cc: `@wesleywiser`

…roalbini

Retry clang+llvm download

We've been seeing a pretty high rate of spurious network failures (e.g., openssl
connection reset by peer). Not clear why, but let's add a retry.

r? `@pietroalbini`

CTFE inbounds-error-messages tweak

* use CheckInAllocMsg::PointerArithmeticTest for ptr_offset error
* nicer errors for some null pointer cases

r? `@oli-obk`

…ts, r=Mark-Simulacrum

Sort rustdoc-gui tests

The rustdoc-gui tests were randomly run. Not really a big issue but I prefer the tests to be sorted.